This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

🤖 Agent-assisted code review (principal-engineer pass). Verified locally: expand_* unit tests pass; traced the warning path.

Approve with minor suggestions — well-scoped, behavior-preserving. Actionable items:

1. OCSF emit block is now copy-pasted 4× in opa.rs (2 validation + 2 expansion, differing only in message prefix). This PR deepens existing duplication. Extract a helper and collapse all four sites:

   fn emit_l7_config_warnings(warnings: &[String], prefix: &str) {
       for w in warnings {
           ocsf_emit!(ConfigStateChangeBuilder::new(ctx::ctx())
               .severity(SeverityId::Medium)
               .status(StatusId::Success)
               .state(StateId::Enabled, "validated")
               .unmapped("warning", serde_json::json!(w))
               .message(format!("{prefix}: {w}"))
               .build());
       }
   }

2. Document access_preset_rules's implicit contract. Now that it's an independently-callable helper, its else branch silently returns REST rules for mcp/jsonrpc protocols — safe only because validate_l7_policies rejects access presets for those before expansion. Add a one-line doc comment stating that assumption so a future caller doesn't misuse it.

3. Nit: serde_json::json!(w.clone()) — w is &String; drop the clone (fold into #1).

Non-blocking design note: the unsupported-preset warning lives in expansion rather than validate_l7_policies (which already returns warnings). Current placement keeps access_preset_rules as the single source of truth for supported presets — reasonable, but worth a comment so nobody "consolidates" it into validation and reintroduces a drifting preset list.

Thanks for your review @russellb. Incorporated all 4 suggestions: https://github.com/NVIDIA/OpenShell/compare/4c0029870a3f9cef2428d16547f63018ade3fde5..059c35caa41c2a7c3141439601548c2e13ba8342

Thanks for the updates! This lgtm.

/ok to test 059c35c

@krishicks Thanks for your approval. Looks like auto-merge hasn't enabled for this PR, would you please help merge it?

Only "e2e / E2E (rust-podman-rootless, ubuntu-26.04)" failed: https://github.com/NVIDIA/OpenShell/actions/runs/29785520611/job/88499391337

E2E test sandbox_create_with_no_keep_cleans_up_after_tty_command failed as --no-keep did not delete adorable-wattlebird in time:

thread 'sandbox_create_with_no_keep_cleans_up_after_tty_command' (18164) panicked at tests/sandbox_lifecycle.rs:135:5:
sandbox adorable-wattlebird should have been deleted automatically
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
test sandbox_create_with_no_keep_cleans_up_after_tty_command ... FAILED

failures:

failures:
    sandbox_create_with_no_keep_cleans_up_after_tty_command

test result: FAILED. 1 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 24.28s

2026-07-20T23:22:26.539977Z  WARN openshell_server::compute: Sandbox failed to become ready sandbox_id=05761aa7-7888-4b11-a746-5a7318bcaa9d sandbox_name=adorable-wattlebird reason=ContainerExited Container exited with code 137

Same test passed on "e2e / E2E (rust-podman-rootless, ubuntu-24.04)": https://github.com/NVIDIA/OpenShell/actions/runs/29785520611/job/88499391279. Seemingly flakiness is not related to this PR change.

I found the same flakiness happened today at PR #2317, https://github.com/NVIDIA/OpenShell/actions/runs/29764446709/job/88429874012 (same job, same test).

There is already an issue tracking it and a PR is opened: #2326, #2340

@krishicks Would it be safe to retry failing test or just merge it as-is? Thanks in advance!